refactor(actions): parse server-action input with zod - #217

Brings all five src/app/**/actions.ts modules in line with the zod convention .coderabbit.yaml already states (lines 94 and 115). Every one of them returned 0 for grep -c zod before this.

Convention conformance, not behaviour change: every existing error code is preserved, no code was merged or split, and no zod message reaches a user.

What changed per file

parseYmd and battleReportUrlProblem moved to a new src/app/payouts/validation.ts so the schemas and their tests can import them — a "use server" file may only export async functions, so nothing testable can live beside the actions.

createOperationAction

Folded into one schema parsed before appraiseLoot, with the date parse and the future-date check as separate schema steps. date_invalid and date_future stay separately reachable — a single collapsing refinement would have been a regression. URL validation still precedes the appraisal call, so a bad scheme never triggers a network call that gets thrown away. todayUtc is threaded in via buildCreateOperationSchema(todayUtc) rather than read inside the schema, keeping the schema a pure function of its inputs.

Error-code preservation

Codes are read back off the rejected issue (issues[0].message, which is what each schema's error: option puts there) rather than restated at the call site, so each code has exactly one spelling. That makes the error: options load-bearing, which is why they are spelled on every rejecting path: z.number().int().positive({ error }) attaches the code to positive alone, so a non-integer would otherwise throw zod's own "Invalid input: expected int, received number".

Per AGENTS.md item 22, both newly load-bearing options were demonstrated with the fix surgically removed and the assertions untouched:

× setMainAction rejects a non-integer characterId with invalid_character_id
× designateHolderAction rejects a non-numeric characterId with invalid_id
AssertionError: expected [Function] to throw error including 'invalid_character_id' but got 'Invalid input: expected int, received…'
AssertionError: expected [Function] to throw error including 'invalid_id' but got 'Invalid input: expected number, recei…'
Test Files  2 failed (2) | Tests  2 failed | 4 passed (6)

The payouts coverage tests derive each code from a real parse rather than a hand-copied list, so a typo'd error: fails them instead of passing a stale map.

Ordering

Every site parses after its auth guard, not before, so an unauthenticated caller gets the guard's own redirect rather than a validation error telling them whether their argument had the right shape.

Notes for the reviewer

• Pre-existing, untouched: Number("0x10") → 16, so a hex spelling of an id is accepted. This is byte-identical to the chain that was there before; changing it would be a behaviour change this PR is not.
• Invented names. admin/accounts' bound arguments had no prior validation and therefore no prior error string, so invalid_account_id / invalid_tier / invalid_status / invalid_list_search / invalid_identity / invalid_character_id are new. They are thrown, never rendered.
• Declined: pinning the 14 emit sites with satisfies OperationErrorCode. The invariant it would enforce is already covered by tests that derive each code from a real parse, and adding a type layer across 14 sites is the adjacent cleanup this task ruled out.
• Out of scope and untouched: the date field on /payouts/[id] (pre-existing gap, deliberately left alone in design sweep 2: work the ranked backlog #214).

Gates